Different internet protocol (IP) devices can provide address analysis and routing capabilities. These include H.323 gatekeepers (GK), SIP redirect servers (RS) and proxy servers (PS), MGCP (media gateway control protocol) media gateway controllers (MGC)
In all cases this type of device attempts to resolve information such as a dialled number, to a destination IP address or IP address and port. When sufficient information is available (for example, a fully dialled telephone number) the resolution is relatively easy to achieve and the device can map the information to a provisioned IP address. However, if the dialled number is not found, the handling of such call is much more difficult and presently is handled inefficiently.
H.323 and other protocols allow a local server to query its peers if an address is not found. For example, if an H.323 gateway uses an admission request message (ARQ) to find an IP address but its GK does not have that entry provisioned, if the GK has several peers, the local GK is able to query its peers to determine if one of those peers has that number. If it does, the peer may respond to the request with information about the number.
However, such a peer query may fail for several reasons depending on the protocol in use. If, for example, a peer H.323 GK was unable to respond in a timely manner, the originating GK may have to proceed with incomplete information. If the GK that did not respond was the one which ‘owned’ the dialled number, the call will fail.
In this situation, one option is to provide a default route for invalid numbers. This may be a route to a default answer gateway which may provide handling from a centralised answer position which will route the number after the caller tells an operator the correct number. However, this labour intensive.
Furthermore, it may be that the number is incomplete rather than invalid. Using the existing protocols, it is not possible to differentiate between an invalid number which must route to an answering position for manual intervention and an incomplete number which may need to be routed to the answering position.
This difficulty is especially visible in H.323. This protocol is “overlap signalling friendly”; meaning that the transmission of the called party digits in multiple messages (overlap signalling) is provided for as an option in the H.323 standard. For example, if an overlap gateway (GW) and an overlap GK have a peer GK which does not support overlap signalling, every call which needs the non-overlap GK to resolve it, could fail because the non-overlap GK may receive a number too short to resolve because it is unable to wait for the remainder of the number to arrive in one or more further message. Thus any calls attempted using overlap signalling and any numbers that are too short to resolve will fail. Each of those calls will require manual intervention to complete. Thus, for example, a call originating in a TDM or ISDN network which may use overlap signalling may not be handled efficiently when making the transition into the IP domain unless all the servers in that domain are overlap capable.
One possible solution is to take advantage of fixed length numbering plans. For example in North America, the plan is a three digit area code, a three digit exchange code and a four digit number. Thus numbers may be held in some way until it is known that the full number has been dialled. This means that calls should only fail through invalid numbers since all numbers must be complete. However, some other countries have variable length area codes (for example in the UK, city codes vary from two to four digits in length). As explained below, this makes such a scheme difficult to implement.
One alternative is to require calls to be held at the user terminal until fully dialled as is done with cell phones. However, legacy phones do not have this capability and digits are usually sent as they are dialled once the phone has gone off hook.
Another possible solution is to hold the call in the network by storing digits until the number is fully dialled, for example, using an intervening server, switch or possibly, a gateway. However, this has several practical shortcomings.
Unless the intervening server has a full dial plan for the destination being called, the server still requires some indication that the user has completed dialling the call. This could be achieved by dialling a special key, by using an end of dial timer or using some other mechanism.
The provision of a full dial plan is impractical. This requires a significant administrative overhead since the server needs to know every possible dial combination in the world and be kept up-to-date with any changes. Also, when the number is invalid, the user still has to dial the full number to achieve “end of dial” before a number is rejected.
The use of timers is also undesirable because the interval between the last digit being dialled and the audible ringback becomes very large. Normal telecom requirements suggest an interval of less than one second. Normal end of dial timers exceed four seconds. Thus if a call breaks out from an IP domain to an overlap capable ISDN domain and then over analogue signalling TDM trunks, such as dial pulse, the time to outpulse the digits on the dial pulse trunk is in the order of seconds. This happens after the last digit is dialled and the call traverses the IP domain so any delays are then added to the existing post dial timer delay. This provides unacceptable network performance.
Another solution is to replace network infrastructure and units with hardware that uses a “dial the number and press send to initiate” scheme. This is unacceptable to most users and is very costly.
A further solution is to accept that many calls will now require human intervention, when the address resolution server sends the call to a central answering position. This greatly slows many calls and also increases the workload at these stations.